Google Developers Japan: WebAssembly が新しいウェブ機能を加速する仕組み

WebAssembly のおかげで実現できた新機能はたくさんありますが、1 つのブログ投稿を丸ごと使ってその一部を紹介しています。

その中には、さまざまな理由で標準プロセスを通過できなかった機能も含まれています。また、現在標準化が進行中で、さまざまなブラウザで実装が進められているものもあります。

標準化と承認を経なくても機能を公開できるので、イテレーション サイクルが年単位から日単位、場合によっては時間単位にまで短縮できます。オリジン トライアルなどのアプローチを使えば、多くの試験運用を行うことはできますが、それでも週単位や月単位のイテレーションが必要になります。イテレーションの速度を変えるということは、その対象自体を抜本的に変革するということです。

機械学習などの分野は進展が速いので、標準ベースのアプローチではついていくことができません。設計が標準化を経てクロスブラウザ実装に移ったころには、すでに新たな進展があり、プロセス全体をやり直さなければならなくなってしまいます。

とは言うものの、標準化が不可欠なことも多い点は変わりません（後述のデメリットのセクションを参照）。標準化が適している場合は、当然標準化を試みる必要があります。

wasm はさまざまなブラウザでサポートされているので、これを使って構築した機能もすべてのブラウザですぐに動作します。機能の相互運用性とクロスブラウザ実装は、デベロッパーにとって最大の悩みです。機能を低レベルプリミティブに移行することで、この懸念の大半を解消できます。

この機能は厳格なセキュリティ サンドボックスがベースになっているため、ネイティブ実装された API よりも格段にセキュリティが向上します。たとえば、Flash がウェブから削除された大きな理由は、複雑なプラグインのセキュリティを十分に強化するのが難しすぎたためです。しかし、今は Flash を WebAssembly で実行でき、セキュリティの懸念の大半が解消されています。

複雑な問題に対するあらゆる新しいソリューションと同じく、WebAssembly にもデメリットや制限がないわけではありません。その中には、仕組み的に避けられないものもあれば、有望なソリューションが存在するものもあります。

WebAssembly は JavaScript の代替ではなく、JavaScript が時代遅れになるわけでもありません。どちらかというと、WebAssembly は JavaScript の機能を拡張するものです。

ユーザーランドに移動するロジックや機能が増えることで、ページのサイズも増大します。バンドルサイズの縮小は優れたユーザー エクスペリエンスにとって最重要なので、これは大きな問題になります。そのため、この機能を使ってバンドルサイズを肥大化させる前に、慎重に検討する必要があります。この点は、小さな e コマースやブログのサイトよりも、大型のウェブアプリで問題になる可能性があります。JavaScript を多用するフレームワークでも、これが長いこと問題になっています。この状況を改善するため、さまざまなソリューションが考えられるかもしれません。

WebAssembly などのプリミティブは、ほとんどが計算メカニズムであり、OS やデバイス自体にシステムのルート権限でアクセスする機能は一切提供されていません。ハードウェア アクセス（USB や Bluetooth）、画面やウインドウの管理、入力コントロール、ファイル システム、クリップボードなどの機能にアクセスする場合は、今後もプラットフォーム レベルの API が必要になります。Chromium の Fugu プロジェクトは、Chromium ベースのブラウザでこれらのすべての事例を実現しようとするものですが、他のブラウザでの実装も必要になります。

WebAssembly は、すでにブラウザの新機能実現に活用されていますが、それ以上に、根本的に新しい方法で機能の開発方法にアプローチします。何かを改善する最善の方法は、その改善方法を改善することです。すると、2 次曲線的な成長を遂げることができます。どのような新しいパラダイムにもメリットとデメリットがあります。しかし、総合的に見れば、WebAssembly は、あらゆるブラウザとデベロッパーにとって新しいアプローチであると言えます。これを使って皆さんとともに開発を進めていくのが楽しみでなりません。